Systems and methods for data migration in a clustered file system

ABSTRACT

Systems and methods for providing more efficient handling of I/O requests for clustered file system data subject to data migration or the like. For instance, exemplary systems can more quickly determine if certain files on primary storage represent actual file data or stub data for recalling file data from secondary storage. Certain embodiments utilize a driver cache on each cluster node to maintain a record of recently accessed files that represent regular files (as opposed to stubs). A dual-locking process, using both strict locking and relaxed locking, maintains consistency between driver caches on different nodes and the data of the underlying clustered file system, while providing improved access to the data by the different nodes. Moreover, a signaling process can be used, such as with zero-length files, for alerting drivers on different nodes that data migration is to be performed and/or that the driver caches should be flushed.

RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.12/722,200, filed Mar. 11, 2010, which claims priority benefit from U.S.Provisional Patent Application No. 61/165,109, filed Mar. 31, 2009,entitled “SYSTEMS AND METHODS FOR DATA MIGRATION IN A CLUSTERED FILESYSTEM.” Each of the foregoing applications are hereby incorporatedherein by reference in their entirety.

BACKGROUND

1. Field

Embodiments of the invention relate to data migration and, inparticular, to systems and methods for managing access to primary ormigrated data in a clustered file system environment.

2. Description of the Related Art

Current information management systems employ a number of differentmethods to perform storage operations on electronic data. For example,data can be stored in primary storage as a primary copy or in secondarystorage as various types of secondary copies (e.g., backup copies,archive copies, hierarchical storage management (“HSM”) copies), whichare typically intended for long-term retention before some or all thedata is moved to other storage or discarded.

In certain storage systems, when the data of a file is moved fromprimary to secondary storage, the file in primary storage is replacedwith a stub file that indicates the new location of the migrated data onsecondary storage. In certain examples, the stub comprises a relativelysmall, truncated file (e.g., several kilobytes) having the same name asthe original file. The stub file can also include metadata thatidentifies the file as a stub and that can be used by the storage systemto locate and restore the migrated data to primary storage. Thisstubbing process is generally performed transparently to the user by astorage service and file system driver.

Reading each file following a file system operation (e.g., read, write,rename request) to identify if the file is a stub or an actual file canbe unduly time-consuming. As a result, certain stand-alone file systemscan utilize an index or cache to record whether or not arecently-accessed file is a stub. However, such a configuration becomesunworkable in a clustered file system as the same file can beindependently accessed and modified (e.g., migrated) by any one ofvarious cluster nodes. That is, in the cluster configuration, caching offile/stub information becomes more cumbersome because a file systemdriver associated with one node of the cluster does not necessarilycontrol or monitor all I/O paths to the stored files' data and does notknow when a file has been modified or migrated by another node.

SUMMARY

In view of the foregoing, a need exists for improved systems and methodsthat manage access to shared data that can be moved within a storageenvironment, such as a clustered file system. For instance, there is aneed for more efficient systems and methods for handling I/O requestsfor shared file system data after such data has been migrated tosecondary storage.

In certain embodiments of the invention, systems and methods aredisclosed that utilize a driver-based inode cache on each cluster nodeto maintain a record of recently accessed files that represent regularfiles (as opposed to stubs). Certain further embodiments of theinvention implement a dual-locking process for maintaining consistencybetween driver caches on different nodes and the data of the underlyingclustered file system. In yet further embodiments, a signaling processis used by migration systems disclosed herein for alerting file systemdrivers on different cluster nodes that data migration is to beperformed and/or that driver caches should be flushed.

In certain embodiments, a method is disclosed for coordinating access todata in a storage management system. The method includes storing in ashared file system on a primary storage device a plurality of filescomprising a first plurality of regular files and a plurality of stubfiles, the plurality of stub files being associated with a secondplurality of regular files having been migrated to secondary storage.The method also includes maintaining in a first driver cache of a firstcomputer a first indication of first inodes associated with at least oneof the first plurality of regular files on the primary storage deviceand maintaining in a second driver cache of a second computer a secondindication of second inodes associated with at least one of the firstplurality of regular files on the primary storage device. The methodfurther includes requesting with each of the first and second computersa read-only lock on a signal file on the shared file system to determinewhether or not a migration operation is about to occur with respect toat least one of the first plurality of regular files on the primarystorage device. When the request for the read-only lock on the signalfile is denied of at least one of the first and second computers, themethod includes clearing the respective first and/or second indicationsfrom the respective first and/or second driver caches of the at leastone of the first and second computers. When the request for theread-only lock on the signal file is granted to at least one of thefirst and second computers, the method further includes unlocking thesignal file and re-requesting the read-only lock on the signal fileafter a predetermined period of time.

In certain embodiments, a system is disclosed for coordinating access todata in a shared storage environment. The system comprises a firstcomputer including a first memory storing copies of first inodes in ashared file system that represent first data files that have not beenmigrated from primary storage to secondary storage and a second computerincluding a second memory storing copies of second inodes in the sharedfile system that represent second data files that have not been migratedfrom primary storage to secondary storage, the first and second memoriesnot storing copies of inodes that represent stub files. The system alsocomprises first and second file system drivers executing on,respectively, said first and second computers, each of the first andsecond file system drivers being configured to request a shared lock ona signal file on the shared file system. When the request for the sharedlock on the signal file is denied of at least one of the first andsecond file system drivers, the respective copies of the first and/orsecond inodes are cleared from the respective first and/or secondmemories. When the request for the shared lock on the signal file isgranted to at least one of the first and second file system drivers, thesignal file is unlocked and a request for the shared lock on the signalfile is made again after a predetermined period of time.

In certain embodiments, a system is disclosed for coordinating access todata in a shared storage environment. The system comprises: first meansfor storing on a first computing device a first indication of firstinodes in a shared file system that represent first data files that havenot been migrated from primary storage to secondary storage; and secondmeans for storing on a second computing device a second indication ofsecond inodes in the shared file system that represent second data filesthat have not been migrated from primary storage to secondary storage,the first and second means for storing not storing indications of inodesthat represent stub files. The system also includes: third means forrequesting a non-exclusive lock on a signal file on the shared filesystem to determine whether or not a migration operation is about tooccur on data in the shared file system; and fourth means for requestinga non-exclusive lock on the signal file on the shared file system todetermine whether or not a migration operation is about to occur atleast on at least one of the first and second data files. When therequest for the non-exclusive lock on the signal file is denied of atleast one of the third and fourth means for requesting, the first and/orsecond indications of the, respective, first and/or second means forstoring are cleared. When the request for the non-exclusive lock on thesignal file is granted to at least one of the third and fourth means forrequesting, the signal file is unlocked and another request is made withthe at least one of the third and fourth requesting means after apredetermined period of time for the non-exclusive lock on the signalfile.

In certain embodiments, a method is disclosed for coordinating access todata in a storage management system. The method comprises maintaining ina first memory of a first computer a first indication of first inodes ina shared file system that contain entire data of one or more firstfiles. The method further includes maintaining in a second memory of asecond computer a second indication of second inodes in a shared filesystem that contain entire data of one or more second files. The methodalso includes requesting with each of the first and second computers anon-blocking lock on a signal file on the shared file system, the signalfile being indicative of whether or not a migration operation isoccurring and/or is to occur; and when the request for the non-blockinglock on the signal file is denied of at least one of the first andsecond computers, clearing the respective first and/or second indicationfrom the respective first and/or second memory of the at least one ofthe first and second computers, and when the request for thenon-blocking lock on the signal file is granted to at least one of thefirst and second computers, unlocking the signal file and re-requestingthe non-blocking lock on the signal file after a predetermined period oftime.

For purposes of summarizing the disclosure, certain aspects, advantagesand novel features of the inventions have been described herein. It isto be understood that not necessarily all such advantages may beachieved in accordance with any particular embodiment of the invention.Thus, the invention may be embodied or carried out in a manner thatachieves or optimizes one advantage or group of advantages as taughtherein without necessarily achieving other advantages as may be taughtor suggested herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary block diagram of a data migration systemfor a clustered file system, according to certain embodiments of theinvention.

FIG. 2 illustrates a flowchart of an exemplary strict-locking processusable by the data migration system of FIG. 1 for processing file systemoperations.

FIG. 3 illustrates a flowchart of an exemplary dual-locking processusable by the data migration system of FIG. 1 for processing file systemoperations.

FIG. 4 illustrates a flowchart of an exemplary migration signal processusable by a migration service of a single node in the data migrationsystem of FIG. 1.

FIG. 5 illustrates a flowchart of an exemplary driver signaling processusable by a single node in the data migration system of FIG. 1.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

Systems and methods disclosed herein provide for improved data accessmanagement in a shared storage system. In particular, certainembodiments of the invention provide for more efficient handling of I/Orequests for clustered file system data that is subject to datamigration or other information life cycle management (“ILM”) services.For instance, such systems can more quickly determine whether or notcertain files on primary storage represent actual file data or stub datafor recalling the file data from a secondary storage location.

Certain embodiments of the invention utilize a driver-based inode cacheon each cluster node to maintain a record of recently accessed filesthat represent regular files (as opposed to stubs) on primary storage. Adual-locking process, using a combination of strict-locking andrelaxed-locking procedures, can be implemented for maintainingconsistency between driver caches on different nodes and the data of theunderlying clustered file system, while also providing improved accessto the data by the different nodes. Moreover, a signaling process can beused, such as with zero-length files, for alerting file system driverson different cluster nodes that data migration is to, and/or can, beperformed and/or that the driver caches should be flushed.

The features of the systems and methods will now be described withreference to the drawings summarized above. Throughout the drawings,reference numbers are re-used to indicate correspondence betweenreferenced elements. The drawings, associated descriptions, and specificimplementation are provided to illustrate embodiments of the inventionand not to limit the scope of the disclosure.

In addition, methods and functions described herein are not limited toany particular sequence, and the blocks or states relating thereto canbe performed in other sequences that are appropriate. For example,described blocks or states may be performed in an order other than thatspecifically disclosed, or multiple blocks or states may be combined ina single block or state.

FIG. 1 illustrates an exemplary block diagram of a data migration system100, according to certain embodiments of the invention. In certainembodiments, the data migration system 100 advantageously expedites theprocessing of file system requests by: (1) accessing data in primarystorage, or (2) restoring migrated data from secondary storage. Forinstance, the data migration system 100 can facilitate determiningwhether or not a requested file on primary storage comprises the actualfile data or a stub file.

As shown, the data migration system 100 comprises a shared storageconfiguration, such as a clustered file system environment. Forinstance, the data migration system 100 can comprise a distributed filesystem in which a plurality of servers transparently provides servicesto a plurality of clients. In certain embodiments, the data migrationsystem 100 comprises a UNIX clustered file system that operates, forexample, according to the Portable Operating System Interface (POSIX)standard. In certain embodiments, the data migration system 100 cancomprise a General Parallel File System (GPFS), a PolyServe file system,a common file system (CFS), combinations of the same or the like.

The illustrated data migration system 100 includes a plurality of clientsystems or devices 102 that communicate with a primary storage 104 and asecondary storage 106 through a switch 108. In certain embodiments, theclient devices 102 can comprise any computing device capable ofaccessing and/or processing data on a storage volume. In certainembodiments, the client devices 102 comprise server computers. In yetother embodiments, each client device 102 can comprise a workstation, apersonal computer, a cell phone, a portable computing device, a handheldcomputing device, a personal digital assistant (PDA), combinations ofthe same or the like.

The primary storage 104 can include any type of media capable of storingdata. For example, the primary storage 104 can comprise magneticstorage, such as a disk or a tape drive, or other type of mass storage.In certain embodiments, the primary storage 104 can comprise one or morestorage volumes that include physical storage disks defining an overalllogical arrangement of storage space. For instance, disks within aparticular volume may be organized as one or more groups of redundantarray of independent (or inexpensive) disks (RAID). In certainembodiments, the primary storage 104 can include multiple storagedevices of the same or different media. Although the primary storage 104is illustrated separate from the client devices 102, it will beunderstood that at least a portion of the primary storage 104 can beinternal and/or external (e.g., remote) to the one or more of the clientdevices 102.

In certain embodiments, data stored on the primary storage 104 isadvantageously organized and/or cataloged through a file system 110. Inyet further embodiments, the client devices 102 of the data migrationsystem 100 can access the data on the primary storage 104 and/orsecondary storage 106 either directly or through means other than theswitch 108.

As shown, each of the client devices 102 comprises one or moreapplications 112 residing and/or executing thereon. In certainembodiments, the applications 112 can comprise software applicationsthat interact with a user to process data on primary storage 104 and mayinclude, for example, database applications (e.g., SQL applications),word processors, spreadsheets, financial applications, managementapplications, e-commerce applications, browsers, combinations of thesame or the like. In particular, the applications 112 are able tointerface with the file system 110 and data on the primary storage 104through a corresponding file system driver 114.

Each of the client devices 102 further comprises a migration service 116configured to transfer data from primary storage 104 to secondarystorage 106. In certain embodiments, the migration service 116 comprisesa userspace backup application. For instance, the migration service 116can be configured migrate data from primary storage 104 to secondarystorage 106 (e.g., tape or magnetic storage) based on one or morestorage polices, criteria defined by the user, combinations of the sameor the like. In yet other embodiments, the migration service 116 isconfigured to perform one or more of the following copy operations:creation, storage, retrieval, auxiliary copies, incremental copies,differential copies, HSM copies, archive copies, ILM copies or the like.

In certain embodiments, when the migration service 116 moves data fromprimary storage 104 to secondary storage 106, the migration service 116replaces the original data on the primary storage 104 with a stub filein order to conserve space on the primary storage 104. This stub, asdiscussed above, can comprise metadata that allows for the actual datato be restored from secondary storage 106 when requested, for example,by the application 112.

For instance, in certain embodiments of the invention, components of thedata migration system 100 can use Data Management API (DMAPI) persistentfile attributes to store metadata and/or mark files as stubs. Otherembodiments can store metadata as plain text data, surrounded bysignatures and/or checksums, inside the stub file.

In certain embodiments, the file system driver 114 is located betweenthe application 112 and the file system 110 and intercepts file systemoperations, such as read, write and rename operations from theapplication 112. When the file system driver 114 detects that theapplication 112 wants to read from a file that has been replaced by astub, the file system driver 114 posts a recall request to the migrationservice 116 and blocks the application 112 from accessing the data untilthe file data has been restored back from secondary storage 106. Incertain embodiments, the migration service 116 advantageously restoresthe migrated data in a manner that is transparent to the application 112that requested the data.

Although the migration service 116 has been described with reference toboth migrating data from primary storage 104 to secondary storage 106,placing stubs, and communicating with the file system driver 114 torestore migrated data, it should be understood that multiple modules canbe used to perform such functions. For example, the data migrationsystem 100 can comprise one or more backup modules that migrate the dataand place stubs in the primary storage 104, while one or more restoremodules are configured to receive the recall requests when the filesystem drivers 114 detect that an I/O request is directed to a stubbedfile. Such restore modules can be configured to obtain the migrated dataand restore the data to primary storage 104.

In certain embodiments, reading each requested file to determine if itrepresents a stub or an actual file data can be a slow and costlyapproach. Thus, as shown, the file system driver 114 of the datamigration system 100 further comprises a driver cache 118, such as adriver-based inode cache. In certain embodiments, the driver cache 118is configured to store information regarding the most recently accessedinodes, such as whether or not a particular inode represents an actualfile and/or a stub.

For instance, whenever a file is being accessed or requested, the filesystem driver 114 can first perform a look-up of the file's inode in thedriver cache 118. If the inode is present in the driver cache 118, thefile system driver 114 can quickly determine that the file is a regularfile without needing to directly access the file.

If information about the file is not present in the driver cache 118,the file system driver 114 can then access the file directly todetermine if the file is a regular file or a stub file. In certainembodiments, the driver 114 reads a portion of the file and parses themetadata to determine if the file is a regular file or a stub file. Ifthe file is a regular file, the driver 114 adds the file's inode to thedriver cache 118. In certain further embodiments, cache pruning and/oradaptive hashing can be used to improve system performance by trackingthe locations of the files and/or whether or not a particular file is anactual file or a stub file.

However, in a clustered file system environment, such as the datamigration system 100, the information between driver caches 118 canbecome inconsistent. Because multiple applications 112 on multipleclient devices 102 can access the same data on the primary storage 104,the file system driver 114 on an individual client device 102 no longerhas exclusive control over the underlying files and may not be aware offile changes made through other file system drivers 114. Thus, in suchcircumstances, it becomes important to prevent other applications 112from accessing the file when that file is being recalled or migrated(e.g., preventing one application 112 from reading a file at the sametime another client device 102 is replacing the file with a stub).

In view of the foregoing, certain methods are disclosed hereinafter thatcan be used by the data migration system 100 to further address such“races” to file data between different nodes in a clustered file systemand to maintain driver cache consistency. In particular, FIGS. 2-5illustrate flowcharts of exemplary processes usable by the datamigration system 100 in managing access to data in a clustered filesystem.

FIG. 2 illustrates a flowchart of a strict-locking process 200 forprocessing file system operations in a clustered file system, accordingto certain embodiments of the invention. In summary, the process 200provides for strict, file system locking of a particular file each timean intercepted I/O call pertains to the file. In certain embodiments,the process 200 reduces races with migration, recall and/or restoreprocesses that can be executed by other cluster nodes and change thestatus of a file while, at the same time, an I/O request for the samefile is being forwarded from another cluster node. For exemplarypurposes, the process 200 will be described with reference to thecomponents of the data migration system 100 of FIG. 1.

As illustrated, the process 200 begins at Block 205, wherein the filesystem driver 114 intercepts an I/O call (e.g., a read or writeoperation) for a particular inode. The file system driver 114 then locksthe corresponding file for read-only (RO) or read-write (RW) access(Block 210). In certain embodiments, the file system driver 114 utilizesthe file system locks available through an fcntl( ) interface.

After the file is locked, the file system driver 114 analyzes thecontents and/or size of the inode (Block 215) to determine if the inodecontains the actual data file or a stub (Block 220). For instance, thefile system driver 114 can read a portion, such as the first block(s),of the file to determine if the file is a regular file. In otherembodiments, the file system driver 114 can determine that the file is astub if the size of the file is on the order of several kilobytes. Inyet other embodiments, the file system driver 114 can access othermetadata relating to the file (e.g., file attributes) to determine ifthe file is a stub.

If the inode does not represent a stub, the file system driver 114forwards the I/O call to the file system 110 to perform the requestedoperation (Block 225). Once the operation is complete, the file systemdriver 114 unlocks the file (Block 230), and the process 200 returns toBlock 205.

On the other hand, if at Block 220 the inode does represent a stub, thefile system driver 114 posts a recall or restore request to themigration service 116 to obtain and restore the file data from secondarystorage 106 to primary storage 104 (Block 235). At Block 240, the filesystem driver 114 unlocks the file and waits for the recall process tocomplete (Block 245), and the process 200 returns to Block 205.

The locking process 200 can be tolerable in environments, such as GPFS,where file system locking is relatively fast. As can be appreciated,however, such an indiscriminate locking process can be relatively slowin other file system environments, such as in PolyServe file systems orCFS environments where file access speed can be impacted dramatically(e.g., up to ten times slower). Moreover, the locking process 200 doesnot enjoy the performance benefits of utilizing the driver cache 118 toidentify stubs.

FIG. 3 illustrates a flowchart of a dual-locking process 300 forprocessing file system operations, according to certain embodiments ofthe invention. In summary, the process 300 provides for both strictlocking and relaxed-locking modes that facilitate driver cacheconsistency with respect to files on primary storage. The strict-lockingmode is used during a relatively short time period when file migrationis completing and the migrated contents of files are being replaced withstubs. The relaxed-locking mode is used by file system drivers morefrequently, such as between migration jobs. For exemplary purposes, theprocess 300 will be described with reference to the components of thedata migration system 100 of FIG. 1.

As illustrated, at Block 305, the file system driver 114 receives an I/Ocall for a particular inode. The process 300 then determines if the filesystem driver 114 for the particular client device 102 is operating in arelaxed-locking mode (Block 310). In certain embodiments, as discussedin more detail below with respect to FIGS. 4 and 5, such a determinationcan be based on a signaling process that alerts the driver to proceedwith the strict-locking mode or the relaxed-locking mode. In yet otherembodiments, other types of signaling, notifications, user-selectableoptions can be used to determine in which mode the driver 114 is tooperate.

If the driver 114 is operating in a relaxed-locking mode, the filesystem driver 114 determines if the requested inode is present in thedriver cache 118 (Block 315). In certain embodiments, the driver cache118 advantageously maintains only information that indicates whichinodes are known to be regular files (not stubs) and is used to expediteaccess to files on primary storage 104 that have not yet been migratedto secondary storage 106.

If the requested inode is present in the driver cache 118, the filesystem driver 114 immediately forwards the I/O call to the file system110 to perform the requested operation (Block 320). The process 300 thenreturns to Block 305.

If the file system drivers 114 are not operating in a relaxed-lockingmode (determined at Block 310) or, if at Block 315, the requested inodeis not present in the driver cache 118, the process 300 commences astrict-locking procedure. In particular, the strict-locking proceduredefined by Blocks 325 through 350 of the process 300 generallycorresponds to the strict-locking process 200 of FIG. 2.

That is, at Block 325 the file system driver 114 locks the file for ROor RW access, and then the contents and/or size of the inode areanalyzed (Block 330) to determine if the inode contains the actual datafile or a stub (Block 335). If the inode does not represent a stub, thefile system driver 114 adds an entry to the driver cache 118 identifyingthe inode as having a regular file (Block 340).

The file system driver 114 then forwards the I/O call to the file system110 to perform the requested operation (Block 345). Once the operationis complete, the file system driver 114 unlocks the data file (Block350), and the process 300 returns to Block 305.

On the other hand, if at Block 335 the inode does represent a stub, thefile system driver 114 posts a recall request to the migration service116 to obtain and restore the file data from secondary storage 106 toprimary storage 104 (Block 355). At Block 360, the file system driver114 unlocks the file and waits for the recall process to complete (Block365), and the process 300 returns to Block 305.

In certain embodiments of the process 300, the file system driver 114utilizes byte-range locking to avoid interference with locks created byuser applications. For instance, during one or more blocks of theprocess 300, instead of locking the actual file, access to which isbeing intercepted by the file system driver 114, the file system driver114 can lock a corresponding byte range in a dedicated zero-length file.In certain embodiments, such files are maintained in a directory of aroot folder of each shared volume of the primary storage 104. As oneexample, if a file being accessed has inode number “inode_num”, the filesystem driver 114 can lock byte range [inode_num, inode_num+1] in thezero-length file.

As can be appreciated, the process 300 can significantly increase thespeed of processing I/O calls by using the driver cache 118 to identifyinodes corresponding to regular files since no locking takes place aslong as the file's inode is present in the driver cache 118 and therelaxed mode is active. When the information in the driver cache 118 canno longer be trusted (e.g., when migration is in progress), the process300 will generally follow the strict-locking branch (e.g., Blocks325-350).

Moreover, when operating with two locking modes, it can become importantto implement a signaling procedure that notifies the file system drivers114 on each of the client devices 102 that migration is taking placeand/or is about to take place. With such signaling, the file systemdrivers 114 can flush their respective driver caches 118 since themigration can cause information in the driver caches 118 to no longer beconsistent with the contents of the file system 110.

FIG. 4 illustrates a flowchart of a migration signal process 400 usableby a migration service of a single node in a clustered file system. Ingeneral, FIG. 4 illustrates how a data migration service can signaldrivers to switch between a strict-locking mode (e.g., FIG. 2) and adual-locking mode (e.g., FIG. 3). In certain embodiments, the signalprocess 400 is carried out during a migration operation to alert allnodes of a clustered file system that such migration is taking place.For exemplary purposes, the process 400 will be described with referenceto the components of the data migration system 100 of FIG. 1.

The process 400 utilizes two additional files for facilitating themanagement of data migration information: a token file and a signalfile. The token file is generally RO-locked (e.g., a non-exclusive orshared lock) by file system drivers 114 on each node, and as long as theparticular driver 114 holds this lock, the driver 114 works in therelaxed mode under the assumption that no migration service 116 from anyclient device 102 will try to perform migration on files in primarystorage 104.

The signal file is used by the migration services 116 to notify the filesystem drivers 114 on all the client devices 102 that migration is aboutto begin. In certain embodiments, each of the file system drivers 114has a dedicated thread that periodically attempts to RO-lock the signalfile. As long as such RO-locking is possible, the file system driver 114assumes that there in no migration service 116 currently operating inthe data migration system 100, and the file system driver 114 operatesin a relaxed-locking mode.

However, when the thread of the file system driver 114 determines thatthe signal file is read-write (RW) locked (e.g., an exclusive lock), thefile system driver 114 unlocks the token file and begins to operate in astrict-locking mode. In certain embodiments, the file system driver 114also, at this time, flushes its driver cache 118 because the file systemdriver 114 can no longer be certain that the driver cache 118 isconsistent with the data on the primary storage 104. In certainembodiments, when the file system driver 114 on the final client device102 detects the locked signal file and unlocks the token file, themigration service 116 obtains a RW-lock of the token file and begins themigration/stubbing process.

In certain embodiments, one or both of the token and signal filescomprises a zero-length file stored in a subdirectory of the rootdirectory of the file system 110. Working with such zero-length filescan avoid interference with application-level locks that may be imposedby user applications on the same files.

As shown, the process 400 begins by the migration service 116 placing aRW-lock on the signal file. This action can alert the file systemdrivers 114 that migration/stubbing is about to begin. In certainembodiments, as discussed above, each of the file system drivers 114includes a dedicated thread that periodically attempts to RO-lock thesignal file (e.g., approximately every five seconds). Through theseperiodic lock attempts, once a file system driver 114 discovers that thesignal file is RW-locked, the file system driver 114 determines thatmigration is to begin and releases any RO-lock on the token file.

At Block 410, the migration service 116 monitors the token file todetermine when all the file system drivers 114 have released theirRO-locks on the token file (Block 410). In general, the duration of thismonitoring can take up to the time that is established for the filesystem drivers 114 to periodically check the signal file (e.g.,approximately five seconds).

Once all the locks are released from the token file, the migrationservice 116 RW-locks the token file (Block 415). At Block 420, themigration service 116 also RW-locks a particular data file for writing.This can be especially advantageous in certain embodiments wherein thefile system driver 114 does not trust the contents of its driver cache118 and begins to lock data files during each I/O request. RW-lockingthe data file with the migration service 116 can avoid interference withthe user I/O requests through the file system driver 114.

At Block 425, the migration service 116 stubs the particular data file.After stubbing, the migration service 116 unlocks the data file (Block430) and determines if there are additional files to be stubbed (Block435). If there are additional files, the process 400 returns to Block420 to lock the additional data file for stubbing.

On the other hand, if migration and stubbing are complete, the process400 proceeds with Block 435, and the migration service 116 releases itslocks on both the signal and token files. When, through the repeatedlock attempts of the signal file, the file system driver 114 recognizesthat migration has complete (i.e., there is no longer the RW-lock on thesignal file), the file system drivers 114 again RO-lock the token file,mark the driver caches 118 as valid and begin to repopulate the drivercache 118 entries as files are re-accessed.

FIG. 5 illustrates a flowchart of an exemplary driver signaling process500 usable by a single file system driver 114 in a clustered filesystem. In general, FIG. 5 illustrates how drivers can listen tonotifications sent by a data migration service and switch betweenlocking modes. In certain embodiments, the signal process 500 isexecuted by a thread of each file system driver 114 to control thelocking modes and maintain a driver cache consistent with the filesystem. For exemplary purposes, the process 500 will be described withreference to the components of the data migration system 100 of FIG. 1.

As shown, at Block 505, the file system driver 114 obtains or maintainsa RO-lock of the token file. In certain embodiments, during this block,the file system driver 114 advantageously operates in a relaxed-lockingmode. Moreover, as long as the file system driver 114 holds the RO-lockon the token file, the migration service 116 is prevented from migratingdata files, and the driver cache 118 can be assumed to be consistentwith the data of the file system 110.

At Block 510, the file system driver 114 performs a test lock, such as aRO-lock, of the signal file to determine if the migration service 116 ispreparing to perform migration. As discussed above, in certainembodiments, the file system driver 114 includes a dedicated thread thatperiodically performs this locking attempt.

If at Block 515, the file system driver 114 is able to obtain a lock(e.g., RO-lock) of the signal file, the file system driver 114 proceedsto release the lock of the signal file (Block 520). The file systemdriver 114 then waits a predetermined time period (Block 525) andreturns to Block 510 to perform another test lock of the signal file. Incertain embodiments, the predetermined time period is betweenapproximately two and ten seconds. In further embodiments, thepredetermined time period is approximately five seconds. In yet otherembodiments, the predetermined time period is less than two seconds ormore then ten seconds, or may vary based on a storage policy, auser-defined preference or other criteria.

On the other hand, if at Block 515 the file system driver 114 is notable to lock the signal file (e.g., the signal file is already RW-lockedby the migration service 116), the file system driver 114 flushes itsdriver cache 118 (Block 530) and releases its lock on the token file(Block 535). At this point, the file system driver 114 operates under astrict-locking mode with respect to any I/O requests.

The file system driver 114 continues to monitor for when the signal fileis unlocked, signifying that the migration service has completed thestubbing process (Block 540). As discussed above, this monitoring can beperformed by the dedicated thread of the file system driver 114 thatperiodically checks the signal file to see if it is unlocked. If it isdetermined that the signal file is unlocked, the process returns toBlock 505, wherein the file system driver 114 again RO-locks the tokenfile.

The processes described above with respect to FIGS. 3-5 can, in certainembodiments, provide one or more advantages in managing access to data.For instance, the processes 300, 400 and 500 are independent of thenumber of computer nodes or client devices in the cluster. Such datamigration systems do not require a list of active cluster nodes, andnotifications do not need to be sent to each node regarding migration ofdata.

The processes can also adequately respond to application crashes. Forexample, if the migration service 116 crashes after causing a cluster tooperate in a strict-locking mode, the signal and token files that werelocked by the migration service 116 can automatically be unlocked by thefile system 110. When the file system drivers 114 are alerted to this,they can return to operating in the relaxed-locking mode.

Moreover, if an entire node crashes, this does not cause other filesystem drivers 114 to remain in a strict-locking mode. That is, the filesystem 110 can be configured to automatically release all locks held bya crashed node.

The above-described processes and methods are also file system and/oroperating system independent if the file system 110 operates a fcntl( )locking application programming interface (API) or an equivalent lockingAPI.

Although data migration systems and methods have been disclosed hereinwith respect to particular configurations, other embodiments of theinvention may take on different arrangements. For instance, otherembodiments of the disclosed data migration systems can implement analternative method for synchronizing driver cache contents. Forinstance, in certain embodiments, each of the driver caches 118 cancommunicate with each other to achieve consistency between theircontents and the underlying clustered file system 110. Such acommunication mechanism can, in certain embodiments, be implementedinside the file system drivers 114 and/or kernel (e.g., the file systemdrivers 114 opening socket connections directly to services running onother cluster nodes). In such embodiments, the synchronizationcommunications between the driver caches 118 can be performedsubstantially simultaneously.

In yet other embodiments, flags associated with shared files on the filesystem could be checked periodically by the file system drivers 114 todetermine if migration has occurred. In yet other embodiments, the filesystem drivers 114 could access a shared driver cache, accessible to allthe drivers, that represents the contents of the primary storage.

Moreover, in certain embodiments of the invention, data migrationsystems and methods may be used in a modular storage management system,embodiments of which are described in more detail in U.S. Pat. No.7,035,880, issued Apr. 5, 2006, which is hereby incorporated herein byreference in its entirety. For example, the data migration system mayinclude multiple clients and/or media agents for accessing data on acommon storage device. Moreover, one or more portions of the datamigration system may be part of a storage operation cell that includescombinations of hardware and software components directed to performingstorage operations on electronic data. Exemplary storage operation cellsusable with embodiments of the invention include CommCells as embodiedin the SIMPANA, QNET, and/or QINETIX storage management systems byCommVault Systems, Inc. (Oceanport, N.J.), and as further described inU.S. Pat. No. 7,454,569, issued Nov. 18, 2008, which is herebyincorporated herein by reference in its entirety.

Systems and modules described herein may comprise software, firmware,hardware, or any combination(s) of software, firmware, or hardwaresuitable for the purposes described herein. Software and other modulesmay reside on servers, workstations, personal computers, computerizedtablets, PDAs, and other devices suitable for the purposes describedherein. Software and other modules may be accessible via local memory,via a network, via a browser, or via other means suitable for thepurposes described herein. Data structures described herein may comprisecomputer files, variables, programming arrays, programming structures,or any electronic information storage schemes or methods, or anycombinations thereof, suitable for the purposes described herein.

Embodiments of the invention are also described above with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products. It will be understood that eachblock of the flowchart illustrations and/or block diagrams, andcombinations of blocks in the flowchart illustrations and/or blockdiagrams, may be implemented by computer program instructions. Thesecomputer program instructions may be provided to a processor of ageneral purpose computer, special purpose computer, or otherprogrammable data processing apparatus to produce a machine, such thatthe instructions, which execute via the processor of the computer orother programmable data processing apparatus, create means forimplementing the acts specified in the flowchart and/or block diagramblock or blocks.

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to operate in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the acts specified in the flowchart and/or block diagramblock or blocks. The computer program instructions may also be loadedonto a computer or other programmable data processing apparatus to causea series of operations to be performed on the computer or otherprogrammable apparatus to produce a computer implemented process suchthat the instructions, which execute on the computer or otherprogrammable apparatus, provide steps for implementing the actsspecified in the flowchart and/or block diagram block or blocks.

While certain embodiments of the inventions have been described, theseembodiments have been presented by way of example only, and are notintended to limit the scope of the disclosure. Indeed, the novel methodsand systems described herein may be embodied in a variety of otherforms; furthermore, various omissions, substitutions and changes in theform of the methods and systems described herein may be made withoutdeparting from the spirit of the disclosure. The accompanying claims andtheir equivalents are intended to cover such forms or modifications aswould fall within the scope and spirit of the disclosure.

1. A method for coordinating access to data in a storage managementsystem, the method comprising: storing in a shared file system on aprimary storage device a plurality of files comprising a first pluralityof regular files and a plurality of stub files, the plurality of stubfiles being associated with a second plurality of regular files havingbeen migrated to secondary storage; maintaining in a first driver cacheof a first computer a first indication of first inodes associated withat least one of the first plurality of regular files on the primarystorage device; maintaining in a second driver cache of a secondcomputer a second indication of second inodes associated with at leastone of the first plurality of regular files on the primary storagedevice; requesting with each of the first and second computers aread-only lock on a signal file on the shared file system to determinewhether or not a migration operation is about to occur with respect toat least one of the first plurality of regular files on the primarystorage device; when the request for the read-only lock on the signalfile is denied of at least one of the first and second computers,clearing the respective first and/or second indications from therespective first and/or second driver caches of the at least one of thefirst and second computers; and when the request for the read-only lockon the signal file is granted to at least one of the first and secondcomputers, unlocking the signal file and re-requesting the read-onlylock on the signal file after a predetermined period of time.